Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/appleip/appleip-minutes-90dec.txt

Text File | 1993-02-17 | 7.9 KB | 314 lines

CURRENT_MEETING_REPORT_


Reported by John Veizades/Apple

APPLEIP Minutes

MacIP

John Veizades led the MacIP discussion which resulted in numerous
changes to the MacIP document.


There was a discussion about broadcasting, and three notes came out of
that talk.


   o Never forward link level broadcasts.
   o It is forbidden to unicast to a router who does directed broadcast
     by unicast explosion.
   o Gateways will follow router requirements document with respect to
     directed broadcasts on subnets.


Two other documents were mentioned, the first an FYI RFC for ATALK AD
and ATALK ATAB. These two protocols are the KIP implementation and not
phase 2 compatible.  Apparently we decided that there is no need for
this RFC.

Appletalk Tunnelling through IP

The tunnelling discussion was lead by Alan Oppenheimer of Apple.  It
started Tuesday afternoon, and continued through the Wednesday meeting.

Tuesday Agenda


   o Walk through the Working Model proposed draft, Alan Oppenheimer.
   o Chooser+:  Screen shots of a hierarchical chooser written by Eran
     Reshef.
   o The ``Magic Gateway'', Brad Parker


The magic gateway does on demand mapping a user on one AppleTalk AS and
a service on a second AppleTalk AS. The mapping information is kept in

                                   1






the user gateway as a tuple for each user.  The mapping is only
available to the user that created it, not to other users on the same
gateway.

Alan has screen shots of the hierarchical chooser.  Everyone at the
meeting greeted that presentation pleasantly.  The reaction to the idea
is positive.  Oppenheimer thinks the user interface needs work.

Brad Parker provided screen shots of the Magic Gateway interface.
Copies of the Working Model proposed draft are available from apple.com.

Wednesday Agenda:


   o Clustering and Remapping additions - Alan Oppenheimer.
   o AppleTalk MIB - Steve Waldbusser.
   o AppleTalk Tunnelling though Foreign Networks, Draft Proposal - Alan
     Oppenheimer.


Clustering:

Clustering is a way to represent combinations of networks and zones as
one entity.  Clustering will be used to represent remote apple
internets.

Possible Remapping Additions:


   o Network number remapping is optional.
   o Static vs.  dynamic remapping.
   o Zone name remapping with some restrictions.
   o General (node) remapping.


Appletalk MIB:


   o Add packets dropped due to bad checksums.
   o MIB is low level AppleTalk statistics intended primarily for
     routers.
   o Alan says routers are not expected to check checksums.  Router
     vendors ARE checking checksums!



                                   2






The MIB was acceptable to the members of the Working Group.  Greg
Minshall has implemented it and says it works.  The MIB document with
the few suggested changes is available via anonymous FTP from
lancaster.andrew.cmu.edu as appletalk-MIB-text.

Appletalk Tunnelling:

Addressing Format


   o DI - Uniquely identified as an appletalk domain.
   o Must be extensible.
   o UI = DI + network number.


The document proposes a general form and an IP form.  The IP form is not
generally accepted because if the IP address is part of the DI, it will
be misused.

A form that was mentioned was 8 bits of length, followed by 8 bits of
authority, followed by the Global Identifier, a Unique ID (of length
length).

Data Format


   o Encapsulation in UDP datagram port 200.
   o Extended DDP header:

      -  DataLink | IP header | UDP header | ?extended header length?  |
         ...
      -  Dest DI | Src DI | reserved 00000000 | type 000002 | DDP header
         | DATA

     The type ``000002'' means ``data''.  Must use UDP header, and each
     DI is padded to an even length.  It was not agreed whether the
     extended header length was needed/desirable.


Routing Information Exchange


   o Provide methodology
   o Provide a protocol
   o Determine which parts of the method are required


                                   3






In addition to the ``axis'' presented in the tunnelling document, a new
axis as mentioned:  coupling ``looseness'', for:


   o Zone info (appearance and disappearance).
   o Network information.
   o Metric changes.


Protocol Summary


   o Initial reliable exchange of a full routing table.
   o (Optional) reliable communication of all changes to the table.
   o (Optional) tickling to handle routers going down.


Reliable Exchange


   o ``One Way'' connection for exchange and update.
   o Network (UI) information sent in ack'd datagrams.
   o Zone information initially send in unack'd datagrams.
   o Background timer polls for lost zone information.


Milo Medin suggests that:


   o Zone info needs to be propogated to all.
   o Network/routing setup on ``demand''.
   o Information updates only when requested, and only at some minimum
     interval.  (The provider tells the requestor what the minimum
     interval is.).


Possible update events:


   o Net added.
   o Net deleted.
   o Net hop count.
   o Zone name changes.


Greg Minshall suggests that these update events are not needed or

                                   4






interesting for users.

Tickling


   o Routers must attempt to notify other connected routers when going
     down.
   o Routers MAY tickle at some minimal rate.
   o If tickling is not used, routers must guard against sending data to
     hosts/paths that may have disappeared.


Issues


   o Zone remapping details
   o Surpassing the 15 hop limit when loops
   o Minimum required routing information exchange, including option
     negotiation
   o Underlying reliable transport mechanism
   o Determination of retransmission times


It was suggested that we do not do zone name remapping, it is a protocol
violation, and applications pass zone names around.  We know about NBP
and RTMP packets, but there will be others.  However if there is no
mapping, then there will be zone name conflicts between ASs.

Underlying Reliable Transport is TCP the transport mechanism for routing
information?  There was a long discussion about this, but the bottom
line was, stick with UDP.

Minimum Routing Exchange


   o Routing protocol
   o Pure configuration
   o Centralized administration
   o Alternate routing protocol


We need to add ZIP get zone list support and zone name change updates to
the routing protocol.

When a zone comes back in a reply, we need to allow unknown net numbers
to come back too.  Oppenheimer points out that not everyone uses NBP, so

                                   5






network numbers must be known in advance.

Server returns update validity interval.  Client asks for update info
when interval expires, and if the client still cares.

It was suggested that the protocol proposed will scale to 100s but not
1000s.

Shiva wants all options negotiable:  what parts of the protocol are
performed, and negotiate who you are talking to to try out special
ideas.

The next meeting is January 9, 1991 before MacWorld in an S.F. hotel.

Attendees

Gregory Bruell           [e-mail]
Philip Budne             [e-mail]
Cyrus Chow               [e-mail]
James Dray               [e-mail]
Karen Frisa              [e-mail]
John Gawf                ncar!cmpatsys!gawf
Michael Horowitz         [e-mail]
Holly Knight             [e-mail]
Philip Koch              [e-mail]
Louise Laier             appleLink@laier1
Nik Langrind             [e-mail]
Joshua Littlefield       [e-mail]
John Mason               [e-mail]
Milo Medin               [e-mail]
Greg Minshall            [e-mail]
Alan Oppenheimer         [e-mail]
Brad Parker              [e-mail]
Mark Seger               [e-mail]
John Seligson            farcomp![e-mail]
Frank Slaughter          [e-mail]
John Veizades            [e-mail]
A. Lee Wade              [e-mail]
Jonathan Wenocur         [e-mail]



                                   6